✨   9월 1일 (수)

📰  나는 프론트엔드를 안다고 말할 수 있을까?

“아는 것은 무엇일까?” 굉장히 철학적인 질문이다. 필자를 괴롭히는 이 질문에 소크라테스는 “나는 내가 모른다는 것을 알고 있다.” 라고 대답한다. 헛소리 같은 이 말에는 개발자로서 갖추어야 할 자질이 잘 드러난다고 생각한다. “잘하는 것과 아는 것은 다르다.” 라는 필자의 말처럼 스스로 무지를 깨닫고 끊임없이 정진하는 태도야말로 바람직하다.

이제 막 코드의 세계로 입문한 나로서는 망망대해를 헤엄치는 기분이다. 한 가지를 잘하기도 어려운데 해야 할 것들이 우주처럼 무한히 확장되는 느낌이 든다.😱

 

✨   9월 2일 (목)

📰  How to Write a Git Commit Message

Git을 학습하면서 commit message에 대해서도 알게되었다. 처음에는 구분을 위해 사용한다는 막연한 생각을 하였였다. 하지만 해당 article을 통해 commit message를 사용하는 이유와 방법에 대해 이해할 수 있었다.

아래의 내용은 필자가 생각하는 Git commit message를 작성하는 규칙을 나타내고 있으며 해당 규칙에 대한 자세한 내용은 본문을 통해 확인할 수 있다.

휼륭한 GIt commit message를 위한 7가지 규칙

• 공백 라인으로 본문과 주제 구분하라.
• 제목 줄을 50자로 제한하라.
• 제목은 대문자로 사용하라.
• 제목에 마침표를 사용하지 말아라.
• 제목은 명령형으로 사용하라.
• 본문을 72자로 줄바꿈하라.
• body를 사용하여 what and why vs. how 설명하라.

 

✨   9월 3일 (금)

📰  내가 토이 프로젝트 경험을 공유하는 이유

좋은 개발자가 갖추어야 할 역량에는 하드 스킬 외에도 소프트 스킬이 필수적이다.
소프트 스킬은 하드 스킬과 다르게 어떤 한 가지 특성을 의미하는 단어가 아니라, 커뮤니케이션, 문제 해결 능력, 리더십, 동기부여와 같이 하드 스킬을 제외한 대부분의 능력을 의미한다.

소프트 스킬은 학원이나 학교같은 교육 기관에서 특정한 커리큘럼을 정해서 가르치기 어려운 종류의 능력이고 결국은 다양한 경험을 통해 자신만의 방법이나 가치관을 확립해나가면서 습득하는 수 밖에 없다.

토이 프로젝트는 직장에서 팀으로 일할 때처럼 실제로 협업을 하는 환경이면서, 동시에 프로젝트를 진행하는 개개인에게는 도전적인 의사결정과 기술을 시험해볼 수 있는 환경이라고 할 수 있다.

 

✨   9월 4일 (토)

📰  README.md 파일을 어떻게 쓰면 좋을까?

REAMDE 파일이란 파일에 대하 정보를 포험하며 일반적으로 컴퓨터 소프트웨어와 함께 배포된다. 문서는 txt, markdown등 다양한 형식으로 저장할 수 있다.

REAME 파일을 통해 다른 사람에게 효과적으로 정보를 제공할 수 있다.

한번에 완벽하게 정리하는 것 보다는 계속해서 업데이트를 하는 것이 중요하다.

README 파일의 일반적 구성

• 프로젝트 구성 안내 (기술 스택)
• 프로젝트 설치 방법
• 프로젝트 사용법
• 프로젝트 기능
• 저작권 및 사용권 정보
• 버그
• 프로그램 작성자 및 도움을 준 사람
• 버전 (엡데이트 소식)
• FAQ

 

✨   9월 5일 (일)

📰   git rebase를 이해하기

rebase란 말 그대로 (re-base)로 베이스를 재배치한다는 뜻입이다.
아직 내 수준에서 내용을 완벽하게 이해하기는 어려운 것 같다. 대략적인 흐름과 rebase가 필요한 이유 정도만 이해할 수 있었다.

요약

• upstream 에서 받아온 변경사항 획득
• merge를 이용해 로컬을 최신화
• git push 하여 내 원격저장소를 최신화

 

✨   9월 6일 (월)

📰   코딩을 배울 때 했던 실수들. 그리고 그 실수들을 피하는 법.

필자가 프로그래밍을 배우기 시작한 초창기에 겪었던 실수와 효과적으로 공부할 수 있는 방법에 대해 서술하고 있다.

효과적으로 공부하기

• 집중력 부족 : 여러 언어를 배우기 보다는 한 프로그래밍 언어를 숙달하는 것이 좋다.
• 튜토리얼의 함정 : 튜토리얼을 따라 하는 것만으로는 부족하며 실제로 힘든 일을 경험해야 개발자가 될 수 있다.
• 추상화에 의존 : 이미 완성된 코드를 가져다 쓰는 것은 편하지만 그 안에서 작동하는 개념과 해결책을 놓치지 말고 호기심을 가지고 도전해라.

 

✨   9월 7일 (화)

📰   우리는 불편함을 어떻게 마주하고 있는가

필자가 새로운 서비스를 오픈하고 겪게 되는 문제점들을 어떻게 해결해가는지를 잘 보여주는 글이다.
더 나은 서비스를 제공하기 위해 필요한 기능을 도입하며 노력하는 모습이 인상적이다.

문제 해결 성과

• 리소스 사용률 향상에 따른 비용 절감
• 소프트웨어 개발 주기 단축
• 쿠버네티스의 자가치유 기능을 바탕으로 서비스 안정성 증가
• 배포 시스템 최적화
• 컨테이너 기반 개발 경험

 

✨   9월 8일 (수)

📰   개발자가 블로그를 운영해야 할 이유

한 달 전만해도 내가 블로그에 글을 쓰고 있을 거라고는 상상할 수 없었다. 평소 SNS도 일절 하지 않고 누군가 내 글을 보는 것은 너무 창피한 경험일 것 같았다.

블로그를 시작하게 된 것은 단순히 배운 것을 기록할 용도가 필요했기 때문이다. 또한 공부를 하며 많은 블로그의 도움을 받았기에 나도 그런 경험을 해보고 싶었다.

필자는 개발자로서 블로그를 운영하며 많은 혜택을 받았다고 서술하고 있으며 블로그 운영을 다른 사람들에게 많이 권하고 있다고 한다.
아래의 내용은 필자가 정리한 블로그 운영의 장점과 어떤 글로 시작하면 좋은지에 대한 경험이 담겨있다.

블로그의 운영의 장점

• 정확한 지식을 얻을 수 있다.
• 좋은 동기가 된다.
• 새로운 기회가 된다.
• 의외의 부수입으로 이어질 수 있다.

어떻게 시작할 것인가

• 번역
• 배운 것 정리
• 간단한 팁
• 겪었던 실수

 

✨   9월 9일 (목)

📰   깊은 복사와 얕은 복사에 대한 심도있는 이야기

얕은 복사(Shallow Copy)

객체를 복사할 때, 해당 객체만 복사하여 새 객체를 생성한다.
복사된 객체의 인스턴스 변수는 원본 객체의 인스턴스 변수와 같은 메모리 주소를 참조한다.
따라서, 해당 메모리 주소의 값이 변경되면 원본 객체 및 복사 객체의 인스턴스 변수 값은 같이 변경된다.

깊은 복사(Deep Copy)

객체를 복사 할 때, 해당 객체와 인스턴스 변수까지 복사하는 방식.
전부를 복사하여 새 주소에 담기 때문에 참조를 공유하지 않는다.

출처: 티끌모아 로키산맥 🏔

• Array.prototype.slice : 배열을 깔끔하게 복사할 때 사용, 중첩 구조 복사를 제대로 수행할 수 없다는 단점이 있다.

• Spread Operator : 객체가 이터러블임이 확인이되면 for-loop 과 같은 단순한 반복문을 통해 모든 요소를 하나씩 옮겨 담는다. 펼침 연산자 중첩 구조를 복사하지 못한다.

• JSON.parse & JSON.stringify : 중첩 구조를 복사할 수 없는 이터러블 순회를 해결할 수 있다.

• Lodash, Ramda : 완전한 깊은 복사를 구현

 

✨   9월 10일 (금)

📰   주니어, 미드레벨과 시니어 개발자의 차이점

주니어, 미드레벨, 시니어 개발자는 프로그램 경험으로 나뉘는 것이 아니다.

미드레벨과 주니어 개발자와 시니어 개발자를 구분하는 차이점

• 디자인패턴, 아키텍처, 테스트자동화, 성능, 보안 등 지식
• 코드를 처음보는 개발자가 새로운 기능 추가 / 버그 수정이 가능
• 유지보수와 확장성을 염두에 두고 작성

주니어 개발자의 특징

• 동작하는 소프트웨어를 좋은 소프트웨어로 인식
• 주니어는 간단한 코드보다 멋진 코드를 선호

주니어 > 미드레벨

• 전체 개발 과정을 최소한 두 번 반복
• 디버깅을 통해 프로세스 진행 상황 이해
• 아키텍처, 성능, 보안 등 학습

미드레벨 > 시니어

• 아무도 모르는 작업을 수행할 준비
• 회사 내에서 사용중인 모든 도구과 애플리케이션에 대한 이해

 

✨   9월 11일 (토)

📰   기존의 사고 방식을 깨부수는 함수형 사고

• 객체 지향적인 사고에 익숙해진 필자가 함수형 패러다임을 학습하기 위한 고민을 엿볼 수 있는 글이다.

함수형 프로그램의 장점

• 높은 수준의 추상화를 제공한다.
• 함수 단위의 코드 재사용이 수월하다.
• 불변성을 지향하기 때문에 프로그램의 동작을 예측하기 쉬워진다.

높은 수준의 추상화

• 추상화란 작업을 수행할 때 그 이면에 존재하는 복잡한 것들을 간단한 것처럼 보이게 만들어주는 것을 말한다.
• 추상화가 잘 되어있는 프로그램은 작동 방식을 모르더라도 해당 기능을 편하게 사용할 수 있다.

명령형과 선언형의 사고 방식

• 명령형 프로그래밍은 문제를 어떻게 해결해야 하는지 컴퓨터에게 명시적으로 명령을 내리는 방법을 의미하고, 선언형 프로그래밍은 무엇을 해결할 것인지에 보다 집중하고 어떻게 문제를 해결하는 지에 대해서는 컴퓨터에게 위임하는 방법을 의미한다.

 

✨   9월 12일 (일)

📰   수학에서 기원한 프로그래밍 패러다임, 순수 함수

• 프로그래밍 함수에서 벗어나 순수 함수의 패러다임을 통해 기존에 가지고 있던 문제점들을 해결하기 위한 방법에 대한 글이다.

수학에서의 함수

• 정의역은 함수의 input, 치역은 함수의 output에 사용될 수 있는 값의 집합
• 동일한 인풋(인자)에는 항상 동일한 결과를 내야한다.
• 함수 외부의 상태를 변경하거나, 외부의 상태에 영향을 받아서는 안된다.

프로그래밍에서의 함수

• 수학의 함수에서 “어떤 값을 던져주면 뭔가를 계산한다”라는 개념만 들고 온 것에 불과 하다.
• 동일한 인풋(인자)에는 항상 동일한 결과를 만들어 내지 않는다. Math.random Date.prototype.getTime
• 외부 상태의 변화에 따라 결과 값도 변경되기 때문에 함수의 동작을 예측할 수 없다. addState 함수

순수한 수학적 함수로 회귀하자

• 테스트가 쉬워진다.
• 개발자가 예측 가능한 어플리케이션을 개발하기 쉽다.
• 좋은 모듈화의 조건 중 하나인 높은 응집도에 부합한다.

 

✨   9월 13일 (월)

📰   변하지 않는 상태를 유지하는 방법, 불변성

불변성이란?

• 상태의 변경이 발생하지 않는 것을 말한다.
• 상태의 변경 : 메모리에 저장된 값을 변경하는 모든 행위, 변수의 재할당과 같은 행위도 포함된다.

값에 의한 호출과 참조에 의한 호출?

• 원시 자료형을 사용하는 변수들은 모두 값에 의한 호출 방식을 사용한다.
• 함수의 인자로 어떤 변수를 넘길 때 해당 변수가 가지고 있는 값을 그대로 복사하여 함수에게 넘겨주는 방식을 의미하기 때문에, 그 값을 복사하여 새로운 메모리 공간에 저장하고나서 넘겨준다.
• 변수를 통해 접근하는 값은 전혀 다른 메모리 공간에 저장되어 있는 새로운 값이다.
• 변수를 재할당하더라도 원본 변수에 담겨져 있는 값은 변하지 않는다.

• Array, Object와 같은 객체는 참조에 의한 호출 방식을 사용한다.
• 참조에 의한 호출 방식은 “변수가 가리키고 있는 메모리 공간의 주소”를 넘기는 방식이다.
• 이 경우에는 메모리 공간에 저장되어있던 배열을 직접 변경하므로, 상태가 변경되었다고 말할 수 있고, 불변성이 깨진다.

불변성을 지키면 어떤 점이 좋은가요?

• 무분별한 상태의 변경을 막는다.
• 상태의 변경을 추적하기가 쉽다

 

✨   9월 14일 (화)

📰   프론트엔드 3대장 비교와 주관적인 최신 웹 동향에 대해

Angular

• 2010년 구글에서 선보인 자바스크립트 프레임워크로 가장 오래된 역사를 가진다.
• MVC 모델을 기반으로 하는 프레임워크로 출발했다.
• 양방향 데이터 바인딩을 통해 화면과 모델 사이를 연결한다.
• 구성에 대한 강제가 비교적 엄격하여 대규모 웹 어플리케이션 개발에 적합한 환경을 제공한다.
• 데코레이터(Decorator)의 사용으로 의존성을 주입한다.
• 의존 관계에 놓인 객체는 상호 작용을 하지만 서로에 대해 알지 못하며, 그로인해 서로에게 주는 영향을 최소하하여 변경에 유연하게 대처할 수 있다.
• 현재는 시장에서 밀렸다는 평이 있으며 구글의 지원이 점점 약해지고 있어 사람들의 관심에서 점차 멀어지고 있다.

React

• 2013년 페이스북에 선보인 자바스크립트 라이브러리로 오늘날 가장 많이 사용되는 프레임워크이자 라이브러리다.
• React 기반의 서드 파티 라이브러리를 조합하여 개발환경을 구축하는 과정에서 정해진 프레임 내 작업이 요구된다.
• 리액트의 핵심은 재사용 가능한 UI 생성과 가상 DOM을 이용한 렌더링에 있다.
• 내부적으로 JSX라는 특별한 문법을 사용된다. 이는 자바스크립트를 확장한 문법으로 리액트의 기본 단위가 되는 컴포넌트를 생성하는데 사용되는 문법이다.
• 진리의 원천(Source of Truth)라고 표현하는 단방향 데이터 흐름만 지원한다.
• 생태계가 웹에만 국한되어 있지 않다. 웹, 모바일 그리고 데스크탑 프로그램까지 모두 React를 사용해 구현할 수 있다.

Vue

• 2014년 두 프레임워크 출시 이후에 출시되었으며 두 프레임워크의 좋은 점을 모두 흡수할 수 있었다.
• 컴포넌트 개념을 그대로 적용하여 재사용성을 높이고 가상돔 역시 도입하여 렌더링 성능을 최적화했다.
• 다른 프레임워크에 비해 비교적 쉽게 배울 수 있다.
• UI를 구성하는데 HTML을 기반으로 하는 평범한 템플릿을 사용한다.
• 양방향 데이터 바인딩을 지원한다.
• 두 프레임워크와 비교해서 상대적으로 더 작은 용량을 가지고 있고, 성능적으로 더 빠른 렌더링이 가능하다.
• 데이터가 직접적으로 변경되는 것을 용인한다.

 

✨   9월 15일 (수)

📰   React 상태 관리의 과거, 현재, 그리고 미래

• React의 상태 관리 도구는 마치 거칠고 투박한 공구 벨트와 같으며 언제 어떤 공구를 사용해야 하는 건지 알기 어렵다.

과거

• React의 컴포넌트 모델은 재사용과 분해가 용이한 어플리케이션을 개발할 수 있게 해주었다.
• 각 컴포넌트는 고유한 로컬 상태를 가진다.
• 컴포넌트 간에 로직을 쉽게 공유할 수 있는 새로운 솔루션들이 등장하게 되었다.
• Redux : UI 상태와 서버 캐시 상태의 관리를 통합했다.
• 서버 캐시 상태 : 공유된 Hooks에 로직을 통합하는 것이 쉬워졌고 접근성이 향상되었다.
• React Context : 중첩된 여러 컴포넌트들에 props로 값을 전달하는 코드를 방지할 수 있게 되었다.

현재

• 커뮤니티가 성장하고 다양한 유형의 상태들을 접하게 됨에 따라, 특정 문제 상황 해결에 중점을 둔 세부적인 라이브러리들이 개발되었다.
• 상태 기계 : 상태 관리의 개념이 현대의 상태 관리 문제를 해결할 수 있다는 것을 깨닫게 되었다.
• URL 상태 : 페이지를 새로고침해도 동일한 항목들을 볼 수 있다. 해당 URL은 다른 사람과 공유할 수 있고 그 사람들도 동일한 결과를 확인할 수 있다.

미래

• useSelectedContext Hook : Context의 “일부”만을 선택하여 해당 일부분이 변화했을 때에만 리렌더가 이루어지도록 만들 수 있게 되었다.

 

✨   9월 16일 (목)

📰   누구나 원하는 개발자되기

• 해당 글은 필자가 채용 과정에 참여하며 느낀점들을 정리한 것이다.
• 주요 역량, 이력서, 코딩 테스트, 면접 등 항목으로 나누어 서술하고 있다.
• 여러 팁도 포함되어 있으니 참고하면 많은 도움이 될 것 같다.
• 그 중 주요 역량 항목만 가져와서 나열해 보았다.

주요 역량 항목

• 어떤 프로젝트를 경험했는지
• 어떤 도구/프레임웍을 사용했는지
• 어떤 개발 방법론을 사용했었는지
• 프로젝트에 어떤 책임으로 참여했는지 개발자인지 개발리더인지
• 팀이나 회사에 프로젝트외에 어떤 기여를 했는지
• 프로젝트에서 발생한 기술적인 문제를 어떻게 해결하는지
• 리더쉽, 협업, 커뮤니케이션 스킬

 

✨   9월 17일 (금)

📰   HTTPS에 대해 알아야 할 것들

HTTPS로 가야 하는 이유

• Identity(인증)
• Integrity(무결성)
• Confidentiality(기밀성)
• 신기술(새로운 프로토콜 및 브라우저 API)에 대한 대응

HTTP와 HTTPS의 차이

• HTTP : TCP 핸드셰이크 후에 HTTP 요청/응답으로 서로 어플리케이션 데이터를 주고 받는다.
• HTTPS : HTTP over TLS를 말하며, TCP 핸드세이크 후에 TLS 핸드셰이크를 진행하고 그후부터는 암호화 통신이 시작되며 HTTP 요청/응답을 통해 어플리케이션 데이터를 주고 받는다.

TLS 핸드셰이크 프로토콜

• 매개변수 교환/동의
• 서버인증(Identity)
• 키교환
• 암호화 통신 시작 알림과 변조여부 체크

 

✨   9월 18일 (토)

📰   개발팀이 일을 매듭 짓는 방법

QA

• 개발한 기능과 제품이 정의한 수준 이상의 품질을 보증할 수 있도록 배포 이전에 각종 테스트와 검수를 진행한다.
• QA는 업무 진행을 평가할 수 있는 최소한의 기준이다.
• QA는 디자인/개발팀만의 전유물이 아니며, 참여하는 팀원들 모두가 QA에 영향을 주게 된다.

배포

• 추가/수정한 기능을 앱/웹/서버에 반영하는 작업입니다.

앱

• 애플 앱스토어는 애플에서 앱을 심사합니다. 심사에 통과해야만 앱을 배포할 수 있다. 배포 후 앱스토어에 반영되는 시간이 어느정도 있고, 반영되면 유저가 업데이트해야 추가/수정한 기능이 반영된다.
• 구글 플레이 스토어는 앱을 심사하지 않지만, 스토어에 반영되는 시간이 꽤 있고, 유저마다 이 반영 시간이 다르다. 대략 1시간 내지 많게는 2일 정도 걸린다. 이 또한 유저가 앱을 업데이트 해야 추가한/수정한 기능이 반영됩니다.
• 앱 배포 시 최종적으로 스토어 반영까지 시간이 들기 때문에 배포 후 문제가 터질 경우 다시 반영하는데까지 시간이 소요된다. 때문에 앱 배포 시에는 QA가 정말 중요허다.

웹, 서버

• 앱 배포와는 다르게, 수정 시 바로 배포 가능하다.

코드 퀄리티

• 코드 퀄리티 관리 없이 기능 개발을 진행하면 어느 순간 생산성이 저하되고 버그가 자주 발생한다. 이때가 되면 개발팀은 기능 개발과는 별개로 코드나 기능을 리뉴얼 하거나 소위 “리팩터링”이라고 부르는 코드 정리 작업을 진행해야 한다.

 

✨   9월 19일 (일)

📰   Programming is an Art

• 어떤 사람들은 미학을 실용주의의 적으로 간주한다.
• 하지만 필자는 아름다운 코드는 간결하고 유지 보수가 유리하기 때문에 더 실용적이고 효과적이라고 주장한다.
• 작성된 코드는 미래에 다른 사람들이 읽고 수정해야한다. 스타일에 신경 쓰지 않고 작성한 코드는 누구도 해독할 수 없다.
• 아름다운 코드를 작성하기 위해서는 쓰는 것보다 더 많이 읽는 것이 중요하다.
• 많은 프로그래머들은 기능을 충족하는 코드를 작성하는데 초점을 맞춘다. 이 경우 문제를 이해하지 못한 경우가 많다. 먼저 문제를 이해한 다음에만 문제를 해결하려고 시도해라.
• 코드의 버그 수는 줄 수에 비례하므로 아이디어가 명확하고 우아하게 표현하는 것이 코드 품질에 중요합니다.
• 프로그래머는 기능적 예술가이다

 

✨   9월 20일 (월)

📰   베일 벗은 카카오웹툰, 혁신과 낯섦 사이에서

• 카카오 엔터테이너 대표 曰 “웹툰을 살아 숨 쉬는 것처럼 이용자에게 전하고 게임과 음악, 영화와 드라마로 변주되는 오리지널 IP의 위상과 가치를 직관적으로 전하도록 사용자 경험(UX) 설계 틀을 파격적으로 바꿨다. 완전히 새로운 레벨의 독창적인 디자인을 구현했다.”
• 카카오웹툰의 뷰포트는 현재 서비스 내에서 일어나고 있는 다양한 정보들을 Y축 이동을 통해 접근할 수 있다.
• 카카오웹툰이 다른 서비스와 가장 차별화된 점은 ‘모션 그래픽’이다.
• 누끼 캐릭터를 활용한 모션그래픽에서 더 나아가 배경이나 이펙트 등을 적극 활용함으로써 마치 한 편의 애니메이션을 보는 느낌이다.
• 몇 년 전까지만 하더라도 웹툰은 지면 만화와 동일시 되었지만 현재는 영화나 드라마의 단골 소재로 사용되면서 IP의 위상이 달라졌다.
• 카카오웹툰의 모션을 입은 캐릭터와 배경을 보면 아직 2차 콘텐츠화되지 않은 웹툰들에서도 충분히 앞으로의 진로를 감지할 수 있다.
• 카카오웹툰은 기존의 서비스들이 가지고 있는 멘탈모델과 꽤 많이 벗어나면서도 낯설지 않은 UX를 만들어냈다.

 

✨   9월 21일 (화)

📰   다크모드의 의의와 웹환경에서의 구현

• 어두운 컬러 계열의 배경, 밝은 컬러 계열의 텍스트 UI테마를 다크모드라 일컫는다.
• 구글은 2018년 안드로이드 9.0(파이)에 다크모드를 도입하였고, 애플은 Mojave MacOS와 iOS 13버전에 기능을 업데이트하였다.

다크모드의 장점

• 시인성(대상이 눈에 쉽게 보이는 정도)이 높아진다.
• 눈의 피로가 줄어든다.

웹 환경에서 구현하기

• 사용자의 시스템 설정 가져오기: prefers-color-scheme

{% gist d2365a67115a1551daca8b56fc982f59 %}

• 사용자가 테마를 선택한다: 루트 요소에 attribute 설정

{% gist 4f5b5463cc9fa68cf793d8aa6d47069b %}

 

✨   9월 22일 (수)

📰   CI/CD가 뭔가요? - 이론편

CI (Continuous Integration)

• CI는 지속적 통합이라는 뜻으로 개발을 진행하면서도 품질을 관리할 수 있다.
• 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있다.
• CI가 나오기 전에는 개발을 끝마치고 배포가 되어야만 코드에 오류는 없는지, 올바르게 동작하는지를 검증하며 코드 품질을 관리할 수 있었다.
• 자동화를 통해 개발자가 빌드와 테스트를 직접 하지 않고도 수정한 코드를 브랜치에 병합하기만 하면 자동으로 빌드와 테스트를 검증할 수 있다.

CD(Continuous Deployment)

• CD는 지속적 배포로 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념으로 지속적 제공(Continuous Delivery)으로 사용한다.

• 지속적 제공은 CI를 통해서 새로운 소스코드의 빌드와 테스트 병합까지 성공적으로 진행되었다면, 빌드와 테스트를 거쳐 github과 같은 저장소에 업로드하는 것을 의미한다.

• 지속적 배포는 이렇게 성공적으로 병합된 내역을 저장소뿐만 아니라 사용자가 사용할 수 있는 배포환경까지 릴리즈하는 것을 의미한다.

• 대표적인 CI/CD의 방법으로는 Travis와 Jenkins가 있다.

Jenkins 구축하기

• 자신의 서버에 알맞게 Jenkins를 설치한다.
• 설치된 Jenkins에 접속해 기본적인 설정을 한다. 플러그인을 설치하고 user를 등록한다. 접속할 url도 지정한다.
• Jenkins 관리에서 자신의 프로젝트에 알맞는 설정을 한다. 다양한 plugin을 추가할 수 있다.
• 새로운 job을 추가해 Jenkins에게 부여하고 싶은 일을 지정한다. 여기서 다양한 파이프라인을 줄 수 있다.

 

✨   9월 23일 (목)

📰   docker 이해하기

도커란?

• 도커는 애플리케이션을 신속하게 구축, 테스트 및 배포할 수 있는 소프트웨어 플랫폼이다.
• 컨테이너 환경에서 독립적으로 애플리케이션을 실행할 수 있도록 컨테이너를 만들고 관리하는 것을 도와주는 도구이다.

컨테이너

• 컨테이너는 격리된 공간에서 프로세스가 동작하는 기술이다.
• 기존의 가상화 방식인 OS 가상화가 아닌 프로세스를 격리하는 방식으로 동작한다.

컨테이너의 특징

• 서버에 여러 컨테이너를 실행하면 독립적으로 실행되어 VM(Virtual Machine)을 사용하는 느낌을 준다.
• 실행 중인 컨테이너에 접속하여 명령어를 입력할 수 있다.
• apt-get 이나 yum 등 운영체제에서 사용하는 패키지 매니저를 통해 설치할 수 있고 사용자도 추가하고 프로세스를 백그라운드로 실행할 수 있다.
• CPU나 메모리 사용량을 제한할 수 있다.
• 호스트의 특정 포트와 연결하거나 호스트의 특정 디렉토리를 내부 디렉토리인 것처럼 사용 가능하다.
• 새로운 컨테이너를 만드는데 1~2초로 매우 빠르다.

이미지

• 도커 이미지는 Docker hub에 등록하거나 Docker Registry 저장소를 직접 만들어 관리할 수 있다.

이미지의 특징

• 도커 이미지의 용량은 보통 수백 MB ~ 수 GB이지만 가상머신에 비하면 작은 용량이다.
• 상태값을 가지지 않고 변하지 않는다.
• 하나의 이미지를 통해 여러 컨테이너를 생성할 수 있고, 컨테이너를 삭제해도 이미지는 변하지 않는다.
• 이미지들은 Docker Hub를 통해 버전 관리 및 배포가 가능하다.
• 도커는 Dockerfile이라는 파일로 이미지를 만든다.

도커 명령어

 

✨   9월 24일 (금)

📰   vim을 대하는 자세

• vim 에디터는 ESC를 누른 시점부터 입력한 키들을 기억하고, 모든 명령어는 커서가 가르키고 있는 곳을 기준으로 한다.

이동 관련 명령어

단어 기준

• w : word의 약자로, 다음 단어의 앞글자로 이동한다.
• e : end의 약자로, 다음 단어의 마지막 글자로 이동한다.
• b : back의 약자로, 이전 단어의 앞글자로 이동 단어의 앞글자로 이해하면 쉽다.

Line(한 줄) 기준

• 0 : Line의 시작으로 이동한다.
• ^ : 공백을 제외한 Line의 시작으로 이동한다.
• $ : Line의 끝으로 이동 regex(정규 표현식)의 익숙하면, ^,$의 개념을 그와 비슷하게 생각하면 된다.

파일 기준

• gg : 파일의 시작
• G : 파일의 끝, 숫자 + G 명령어를 사용하면 원하는 줄의 위치로 바로 이동 가능하다.

f = find, t = till(until)

• 하나의 Line에서 특정 문자를 찾을 때 사용되는 명령어

d = delete, c = change

• 코드를 수정하는 명령어

 

✨   9월 25일 (토)

📰   사용자 경험 개선 1편 - react suspense

react suspense

• 특정 컴포넌트에서 사용되고 있는 데이터의 준비가 아직 끝나지 않았음을 react에 알릴 수 있으며 data fetching 라이브러리와 함께 사용할 수 있는 구조.

data fetching 라이브러리의 역할

• fetching 라이브러리는 워터폴(waterfall) 현상을 막아준다.

suspense의 역할

• 모든 요청을 기다리지 않고도 화면을 렌더링할 수 있다.

data fetching 요청 -> suspense 하위의 컴포넌트에 요청 리소스를 반영 -> suspense에 의해 로딩 UI 렌더 -> 요청 리소스로 data 응답이 들어옴 -> 컴포넌트에 응답 반영

• 경쟁 상태 발생을 방지한다.

경쟁 상태 공유 자원에 대해 여러 개의 프로세스가 동시에 접근을 시도할 때 접근의 타이밍이나 순서 등이 결과값에 영향을 줄 수 있는 상태

 

✨   9월 26일 (일)

📰   사용자 경험 개선 2편 - react concurrent mode

concurrent mode

• 리액트에서 concurrent mode를 사용하면 여러 작업을 동시에 처리할 수 있다.
• 자바스크립트는 싱글 스레드로 동시에 작업을 처리하는 것이 불가능해 보이지만 동시성을 이용하면 가능하다.
• 동시성은 여러 작업을 작은 단위로 나눈 뒤, 그들 간의 우선순위를 정하고 그에 따라 작업을 번갈아 수행하는 방법이다.

여러 작업을 동시에 처리하는 것이 중요한 이유

• 기존 디바운스와 쓰로틀의 한계
• 의미 없는 로딩

Concurrent mode의 동작 원리

• Transition, Loading, Done 총 3개의 렌더링 단계가 있다. 일반적으로 UI 업데이트는 state의 변경에 의해 발생하므로 각 단계는 특정 state 변경의 관점에서 보는 렌더링 단계이다. 오른쪽으로 진행할수록 더 최신 렌더링 단계이다.

 

✨   9월 27일 (월)

📰   [FE] 리액트 상태관리 1부

상태 웹 애플리케이션을 렌더(render)하는데 있어 영향을 미칠 수 있는 값

• 리액트 자체에서 이미 상태를 관리하고 그에 따른 렌더링을 조절하고 있다. ex) useStates
• 여러 컴포넌트가 공통적으로 접근하고 공유하는 경우에도 리액트 자체적으로 해결 가능하다. ex) 상태 끌어올리기(Lifting States Up)

상태 끌어올리기

• 여러 컴포넌트에 공유되어야 할 상태가 있다면, 이 컴포넌트들이 공통으로 가지고 있는 부모 컴포넌트에 상태를 선언하는 것을 말한다.
• 위의 경우 직접적으로 해당 상태를 사용하지 않는 컴포넌트에도 일일이 props 전달이 필요하고 그에 따른 전달 계층 구조가 깊어지는 문제가 발생한다.
• 이를 해결하는 방법 역시 리액트 자체적으로 가능하다. ex) 컴포넌트 합성, Contect API

컴포넌트 합성

• props로 전달될 수 있는 값에 대해 제한이 없다는 것을 이용한 것이다.
• 기존에 방식에선 props로 상태와 이에 대한 setter를 직접 넘겨주었다면, 합성 방식에서는 props로 아예 컴포넌트를 넘겨주는 방식이다.

 

✨   9월 28일 (화)

📰   개발자는 수학을 잘해야할까?

• 컴퓨터는 0과 1을 사용하는 계산기다. 그렇기 때문에 컴퓨터에는 수학적인 내용이 들어갈 수 밖에 없고, 수학적인 개념도 많다.
• 하지만 여기서 말하는 수학은 대부분 명제나 집합, n진법과 같이 중고등학교에서 배웠던 정도의 수준을 말하는 것이다.

알면 도움이 되는 수학 개념 3가지

명제(Proposition)

• 참, 거짓과 같은 논리적인 진릿값
• 명제가 말하는 참과 거짓은 우리가 프로그래밍할 때 사용하는 True, False나 1, 0과 동일한 개념

집합(Set)

• 논리식을 작성할 때 많이 사용된다.
• 논리연산자 &&(AND) = 교집합, ||(OR) = 합집합

수학적 귀납법(Mathematical Induction)

• 주로 어떤 명제가 모든 자연수에 대하여 성립함을 보이기 위해 사용한다.
• 귀납논증은 “지금까지 그래왔으니까 앞으로도 그럴 것이다”라는 느낌이고 연역논증은 “전제가 맞다면 결론도 반드시 맞다”라는 느낌이다.

 

✨   9월 29일 (수)

📰   Git 뉴비를 위한 기초 사용법 - 시작하기

• Git은 분산 버전 관리 시스템이기 때문에 리모트 서버에 있는 소스를 수정하려면 로컬 환경으로 소스를 클론(Clone)하는 과정이 필요하다.

Remote / Origin

• Remote는 말 그대로 리모트 서버 자체를 의미한다.
• Remote 서버는 우리가 자주 사용하는 구글 드라이브나 N드라이브와 같은 클라우드 스토리지를 사용하는 것을 떠올리시면 된다.
• 이 서버를 제공해주는 대표적인 업체가 Github, Bitbucket, GitLab과 같은 회사들이다.
• Git을 사용할 때는 어떤 Remote 서버에 변경 사항을 업로드 할 것인지 정해야하는데, 반드시 하나의 Remote 서버만 사용할 수 있는 것이 아니기 때문에 Remote 서버의 이름을 정해줘야한다. 이때 주로 사용하는 관례적인 이름이 바로 Origin이다.
• 보통은 한 개의 Remote 서버만 운용하는 경우가 대다수이기 때문에 많은 사람들이 Remote와 Origin을 혼용해서 부르곤 한다.

Repository

• 레파지토리(Repository, Repo)는 저장소라는 뜻으로, 리모트 서버 내에서 구분되는 프로젝트 단위이다.
• 일반적으로 한 개의 레파지토리는 하나의 프로젝트를 의미하지만 경우에 따라서 레파지토리 하나에 여러 개의 프로젝트를 구성하기도 한다.
• 레파지토리를 클론받을 때는 해당 레파지토리를 가리키는 URL이 필요한데, 레파지토리의 이름은 URL의 맨 마지막에 .git 확장자를 가지는 방식으로 표현된다.

Branch

• 브랜치는 일종의 독립된 작업을 진행하기 위한 작업 공간의 개념이다.
• 맨 처음 Git을 초기화했을 때 기본적으로 master라는 이름의 브랜치가 하나 생성된다.
• 후 개발하는 기능 또는 버그 픽스에 따라서 브랜치를 새로 생성하고 거기서 작업한 후에 나중에 다시 master로 합치는 것이다.

 

✨   9월 30일 (목)

📰   Git 뉴비를 위한 기초 사용법 - 버전 관리

Merge Conflic

• 소스의 충돌이 발생한 상황이기 때문에 주니어든 시니어든 가리지 않고 평등하게 발생하다.
• <<< HEAD와 ===사이에 들어있는 상단 부분이 현재 브랜치에서 내가 수정한 내용이다.
• ===부터 >>> 커밋 해쉬사이의 내용은 어떤 커밋에서 수정된 내용과 충돌이 발생했는지 알려준다.
• 세가지 선택지를 가질 수 있다.(내 변경 사항을 무시, 상대 변경 사항을 무시, 두 변경 사항 모두 반영)
• 보통 이런 상황에서는 상대에게 변경한 이유를 물어본 후 결정한다.

여러 개의 Branch를 사용하는 이유

• 여러 사람이 한번에 같은 어플리케이션의 코드를 수정하고 있는 상황에서는 방금 위에서 설명한 Merge Conflic가 자주 발생하게된다.
• 그래서 보통 사용자들은 Branch로 주제에 맞는 작업 공간을 따로 나누어서 히스토리를 관리한다.

브랜치 병합(Branch Merge)

• 두 개의 브랜치를 합치는 행위를 만한다.
• Git은 Merge, Merge and Squash, Rebase 특색있는 3개의 브랜치 병합 기능을 제공한다.

Merge

• 제일 기본적인 브랜치 병합 기능으로, 합치려고 하는 대상 브랜치의 변경 사항을 타겟 브랜치에 모두 반영하면서 머지 커밋(Merge commit)을 남긴다.

Merge squash

• –squash 옵션은 해당 브랜치의 커밋 전체를 통합한 커밋을 타겟 브랜치에 Merge하는 옵션이다.
• 대상 브랜치의 모든 커밋을 모아서 하나의 커밋으로 합치고 타겟 브랜치에 Merge하는 방식이다.

Rebase

• Merge와 차이는 합치는 방식이다.
• Rebase는 단순히 합치는 것이 아니라 말 그대로 브랜치의 베이스를 변경하는 것이다.
• Rebase의 장점은 바로 깔끔한 커밋 히스토리를 만들어 준다는 것이다